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Field of the Invention 

The present invention relates generally to devices and methods 
for video compression, and more particularly to devices and methods 
for video compression of motionless images. 

Description of the Prior Art 

Video and audio signals making up a conventional television 
broadcast may be digitized and then compressed in accordance with 
standards established by the International Organization for 
Standardization ("ISO") and International Electrotechnical 
Commission ("IEC") . One of these standards, ISO/IEC 11172, is 
generally identified by the popular name MPEG-1. A technologically 
related standard, ISO/IEC 13818, is identified by the popular name 
MPEG-2. The MPEG-1 and MPEG-2 standards respectively define a 
serial system stream, i.e. a bitstream that contains both com- 
pressed video and audio data, that is well suited for quality: 

1. video playback from digital storage media such as a 
hard disk, CD-ROM, or digital video disk ("DVD"); and 

2. transmission such as over a cable antenna television 
("CATV") system or high bit rate digital telephone 



system, e.g. a Tl, ISDN Primary Rate, or ATM digital 



telecommunications network. 
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The MPEG-1 and MPEG-2 standards are hereby incorporated by 
reference. 

The block diagram of FIG. 1 graphically illustrates a portion 
of the process by which video and audio signals making up a 
5 conventional television broadcast are digitized and then compressed 
during assembly of an MPEG-1 or MPEG-2 serial system stream. In 
the illustration of FIG. 1, a video camera 22, video tape player 
24, video disk player 26 or some other type of video-data 
_ storage-device 28 supply both: 

jMlO 3. an audio signal, indicated in FIG. 1 by an arrow 32, to 



u In accordance with either of the MPEG standards, the encoders 34 
gl5 and 38 first digitize the respective signals 32 and 36, and then 
J . encode the digitized signals 32 and 36 respectively into a MPEG 
compressed video bitstream 42 and a MPEG compressed audio bitstream 
44. Subsequently during the MPEG compression process, as illus- 
trated in FIG. 1 a MPEG serial system stream 46 is assembled by 
20 concatenating packs 48 of compressed data selected respectively 
from the compressed video bitstream 42 and the compressed audio 
bitstream 44. 

In this way, the MPEG serial system stream 46 incorporates the 
compressed video bitstream 42 that may decompressed to present a 



an audio encoder 34; and 



a video signal, indicated in FIG. 1 by an arrow 36, to 



a video encoder 38. 
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succession of frames of video. As illustrated in FIG. 2, the 
compressed video bitstream 42 produced by the video encoder 38 
consists of successive groups of pictures ("GOPs") 52. Each GOP 
52 includes intra ("I") frames 54, predicted ("P") frames 56 , and 
bidirectional ("B") frames 58. An I frame 54 of MPEG compressed 
digital video data is both encoded and decoded without direct 
reference to video data in other frames. Therefore, MPEG com- 
pressed video data for an I frame 54 represents an entire 
uncompressed frame of digital video data. A MPEG P frame 56 is 
both encoded and decoded with reference to a prior frame of video 
data, either reference to a prior I frame 54 or reference to a 
prior P frame 56. A B frame 58 of MPEG encoded digital video data 
is both encoded and decoded with reference both to a prior and to 
a successive reference frame, i.e. reference to decoded I or P 
frames 54 or 56. The MPEG-1 and MPEG-2 specifications define a GOP 
52 to be one or more I frames 54 together with all of the P frames 
56 and B frames 58 for which the one or more I frames 54 are a 
reference. MPEG-2 operates in a manner analogous to MPEG-1 with an 
additional feature that the I frames 54, P frames 56, and a B 
frames 58 of the MPEG-1 GOP 52 could be fields of the I frames 54, 
P frames 56, and a B frames 58, thus permitting field-to-field 
motion compensation in addition to frame-to-frame motion compensa- 
tion. 
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Regardless of whether an I frame 54, a P frame 56 , or a B 
frame 58 is being compressed, in performing MPEG compression each 
successive frame 62 of uncompressed digital video data is divided 
into slices 64 representing, for example, sixteen (16) immediately 
5 vertically-adjacent, non-interlaced television scan lines 66. An 
MPEG-1 slice 64 can be defined to specify an entire frame of 
decompressed video. However, an MPEG-2 slice 64 can be defined to 
specify video that has a maximum height of one slice 64, i.e. 
_ sixteen (16) immediately vertically-adjacent, non-interlaced 
fto television scan lines 66, and which spans the frame's width. MPEG 
compression further divides each slice 64 into macroblocks 68, each 

■ jj i ; 

ffj of which stores data for a matrix of picture elements ("pels") 72 
=p of digital video data, e.g. a 16x16 matrix of pels 72. 
u MPEG compression processes the digital video data for each 

pl5 macroblock 68 in a YCbCr color space. The Y component of this 
^ color space represents the brightness, i.e. luminance, at each pel 
" 72 in the macroblock 68. The Cb and Cr components of the color 
space represent subsampled color differences, i.e. chrominance, for 
2x2 groups of immediately adjacent pels 72 within the macroblock 
20 68. Thus, each macroblock 68 consists of six (6) 8x8 blocks of 
digital video data that in the illustration of FIG. 1 are enclosed 
within a dashed line 74. The six (6) 8x8 blocks of digital video 
data making up each macroblock 68 includes: 
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1. four (4) 8x8 luminance blocks 76 that contain brightness 
data for each of the 16x16 pels 72 of the macroblock 68; 
and 

2. two (2) 8x8 chrominance blocks 78 that respectively 
contain subsampled Cb and Cr color difference data also 
for the pels 72 of the macroblock 68. 

In compressing all the macroblocks 68 of each I frame 54 and 
certain macroblocks 68 of P frames 56 and B frames 58, MPEG digital 
video compression separately compresses data of the luminance 
blocks 76 and of the chrominance blocks 78 , and then combines the 
separately compressed blocks 76 and 78 into the compressed video 
bit stream 42. 

Mathematically , the four (4) luminance blocks 76 and two (2) 
chrominance blocks 78 of each macroblock 68 respectively constitute 
8x8 matrices. Referring now. to FIG. .3, compressing each macroblock. 
68 includes independently computing an 8x8 Discrete Cosine 
Transform ("DCT") 82 for each of the six (6) 8x8 blocks 76 and 78 
making up the macroblock 68. The six (6) 8x8 DCTs 82 , only one of 
which is depicted in FIG. 3, respectively map the data of the six 
(6) blocks 76 and 78 into sixty-four (64) frequency coefficients. 
Each frequency coefficient in the DCT 82 represents a weighing 
factor that is applied to a corresponding basis cosine curve. The 
sixty-four (64) basis cosine curves vary in frequency. Low cosine 
frequencies encode coarse luminance or chrominance structure in the 
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macroblock 68. High cosine frequencies encode detail luminance or 
chrominance features in the macroblock 68. Adding together the 
basis cosine curves weighted by the sixty-four (64) DCT coeffi- 
cients reproduces exactly the 8x8 matrix of an encoded block 76 or 
78. 

By themselves , the coefficients of the DCT 82 for a block 76 
or 78 provide no compression. However, because video data for most 
macroblocks 68 lack detail luminance or chrominance features, most 
high-frequency coefficients for the DCTs 82 are typically zero (0) 
or near zero (0) . To further increase the number of zero coeffi- 
cients in each DCT 82, MPEG encoding divides each coefficient by a 
quantization value which generally increases with the frequency of 
the basis cosine curve for which the coefficient is a weight. 
Dividing the coefficients of the DCT 82 by their corresponding MPEG 
quantization values reduces image detail. Large numeric values for 
quantization reduce detail more, but also provide greater data 
compression for reasons described in greater detail below. 

After quantizing the DCT 82, the quantized frequency coeffi- 
cients are processed in a zigzag order as indicated by arrows 
84a-84i in FIG. 3. Applying a zigzag order to the quantized 
frequency coefficients tends to produce long sequences of DCT 
frequency coefficients having zero (0) value. Run-length encoding, 
indicated by an arrow 86 in FIG. 3, is then applied to the zigzag 
order of the quantized DCT coefficients. For those quantized DCT 
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coefficients that differ from the immediately preceding and 
succeeding DCT coefficient along the zigzag path, run-length 
encoding specifies a run-length of zero (0), i.e. a single 
occurrence of the quantized DCT coefficient. Long sequences of 
zero (0) coefficients along the zigzag path depicted in FIG, 3, are 
efficiently encoded using a lesser amount of data. MPEG run-length 
encoding represents each such sequence of consecutive identical 
valued quantized frequency coefficients by a token 88, depicted in 
FIG. 3, which specifies how many consecutive quantized frequency 
coefficients have the same value together with the numerical value 
for that set of quantized frequency coefficients. 

The tokens 88 extracted from the sequence of quantized 
frequency coefficients are then further compressed through Huffman 
coding, indicated by an arrow 92 in FIG. 3. Huffman coding 
converts each token 88 into a variable length code ("VLC") 94. 
MPEG assigns values that are only 2-3 binary digits ("bits") long 
for the VLCs 94 representing the most common tokens 88. Converse- 
ly, MPEG video compression assigns values that are up to 28 bits 
long for the VLCs 94 representing rare tokens 88. The Huffman 
coded VLCs 94 thus determined are then appropriately merged to form 
^ojnpressed video bitstream 42 depicted in FIG. 1. 
"q^ ywhile decoding the compressed video bitstream 42 assembled as 
described above reproduces frames of motion video that are 
generally visually acceptable, reproduced frames of still images, 
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particularly still/ images containing text, are in many instances, 
if not most, visually unacceptable. As described above, the 
process depicted in FIG. 3 of separately computing the DCTs 82 for 
the luminance blocks 76 and the chrominance blocks 78, quantizing 
5 the DCT coeff icijents, zigzag ordering of quantized DCT coeffi- 
cients, run-lenguh encoding, and finally Huffman coding generally 
remove a significant amount of high frequency data from MPEG com- 
pressed I frame* 54. Decoding of I frames 54 from which high 
^ frequency data ihas been removed produces an image having less 
flLO detail, e.g. shatp corners and abrupt transitions from one color or 
m intensity to anpther, than appeared in the uncompressed frame of 
rp video data. However, MPEG compression does not completely discard 
if this high frequency data, i.e. image detail. MPEG compression 
^ attempts to encode this high frequency data into successive P 
Sjl5 frames 56 and B frames 58 that use the I frame 54 as a reference, 
J either directly or indirectly. Consequently, after decoding the 
H lesser detail! in each , decoding subsequent P frames 56 and B 
frames 58 increases, over time, the detail present in the video 
images until pie next I frame 54 is decoded. 
20 For the preceding reasons, image detail in frames 62 decoded 

from the conventional MPEG compressed video bitstream 42 that 
reproduce a still image, particularly a still image containing 
text, tends to be lower at the beginning of each GOP 52 when an I 
frame 54 is decoded, increase during decoding of successive P 
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frames 56 and B frames 58 in the GOP 52, only to decrease again 
upon decoding the next I frame 54, Thus, a decoding of the MPEG 
compressed video bitstream 42 of a still image frequently produces 
a video image that appears to pulse visually, usually at a 
frequency that is identical to the frequency at which GOPs 52 occur 
in the compressed video bitstream 42, e.g. twice per second. This 
visual pulsing of a decompressed MPEG compressed video bitstream 42 
of a still image in many instances makes them commercially 
unacceptable. 

In addition to the conventional MPEG compressed video 
bitstream 42, there also exists another technique for compressing 
the video signal of a conventional television broadcast frequently 
identified as motion JPEG. The compressed video bitstream 42 for 
motion JPEG includes only I frames 54, and therefore omits both P 
frames 56 and B frames 58. Consequently, images decoded from a 
motion JPEG compressed video bitstream having a quality equivalent 
to that of MPEG compressed video require a larger amount of data. 
Alternatively, images decoded from motion JPEG compressed video 
bitstream that have an amount of data equivalent to MPEG compressed 
video possess a lesser quality than decoded MPEG-1 images. 
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BRTEF SUMMARY OP TOE TNV BUTTON 

An object of the present invention is to provide a compressed 
video bitstream that, when decompressed, faithfully reproduces a 
still image. 

Yet another object of the present invention is to provide a 
compressed video bitstream that preserves detail that occur in 
still images. 

Another object of the present invention is to provide a 
compressed video bitstream that preserves sharp corners that occur 
in still images. 

Another object of the present invention is to provide a 
compressed video bitstream that preserves abrupt transitions from 
one color to another that occur in still images. 

Another object of the present invention is to provide a 
compressed video bitstream that preserves abrupt transitions from 
one intensity to another that occur in still images. 

Another object of the present invention is to provide a 
compressed video bitstream that upon being decompressed produces a 
video image that does not appear to pulse visually. 

Yet another object of the present invention is to swiftly and 
efficiently assemble a MPEG compressed video bitstream that, when 
decompressed, faithfully reproduces a still image. 

Briefly, the present invention is a method for producing a 
compressed video bitstream that includes compressed video data for 
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a plurality of frames from data that specifies a single still 
image. A first step in producing the compressed video bitstream is 
fetching the data for the still image, and then encoding the data 
for the still image into data for an intra ("I") frame. The data 
for the I frame is then stored to be combined with other data in 
the compressed video bitstream. 

The compressed video bitstream in accordance with the present 
invention includes at least a single copy of the stored I frame 
together with at least one null frame, and various headers required 
for decodability of the compressed video bitstream. The specific 
headers will vary depending upon the video compression standard, 
e.g. MPEG-1 or MPEG-2, that a decoder processes. Decoding of the 
compressed video bitstream assembled in accordance with the present 
invention produces frames of decoded video that do not appear to 
pulse visually. 

An advantage of the present invention in comparison with 
motion JPEG is that the compressed video bitstream produced in 
accordance with the present invention either is much more compact 
for the same decoded image quality, or upon being decoded produces 
significantly better quality images for an equivalent amount of 
data. 

These and other features, objects and advantages will be 
understood or apparent to those of ordinary skill in the art from 
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the following detailed description of the preferred embodiment as 
illustrated in the various drawing figures. 



BRTEP DESCRIPTION OF THE DRAWINGS 

5 FIG. 1 is a block diagram illustrating portions of the prior 

art conventional MPEG video compression process for forming a 
serial system stream including encoding of a compressed video 
bitstream; 

FIG. 2 is a block diagram illustrating how frames of digital 
yrp.0 video data are processed during formation of the conventional MPEG 
fn serial system stream as depicted in FIG. 1 to extract macroblocks 

5 that consist of luminance and chrominance blocks; 

J FIG. 3 is a block diagram depicting application first of the 

J\ prior art DCT, then run-length coding, and finally Huffman coding 
^15 to luminance and chrominance blocks that make up macroblocks 
*3 extracted from a frame of digital video data as illustrated in FIG. 

6 2} and 

FIG. 4 is a block diagram depicting encoding , in accordance 
with the present invention, a still image, and assembly of the 
20 encoded still image into a MPEG-1 compressed video bitstream. 
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DET»TT.ttn HEflflRTPTTflN 
FIG. 4 depicts the video encoder 38 adapted for encoding still 
images to assemble the compressed video bitstream 42 in accordance 
with the present invention. The video encoder 38 includes an I 
frame encoder 102 that fetches a single frame of still-image data 
104 such as bit-map data for text, as indicated by an arrow 106 in 
FIG. 4. The I frame encoder 102 encodes the still-image data 104 
into data for a single encoded I frame 108 that is stored into a 
high-speed local memory not separately illustrated in any of the 
FIGs. storing the encoded I frame 108. into a high speed, memory 
permits its quick retrieval during subsequent assembly of the 
compressed video bitstream 42. 

Those familiar with MPEG will understand that certain 
parameters may be supplied to the video encoder 38 before the I 
frame encoder 102 encodes the still-image data 104 to specify 
characteristics of the encoded I frame 108. Similarly, those 
familiar with MPEG are aware that MPEG decoders include a buffer 
memory for storing the compressed video bitstream 42 during 
decoding. Because, as described below, each GOP 52 encoded in 
accordance with the present invention for decoding by an MPEG-i 
decoder includes only a single I frame 54, the parameters supplied 
to the video encoder 38 are preferably chosen so the amount of data 
produced for the I frame 54 approaches, but remains less than, the 
storage capacity of the buffer memory included in the decoder. By 
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choosing parameters for MPEG encoding of the still-image data 104 
that produce an amount of data for the I frame 54 which approaches, 
but remains less than, the storage capacity of the buffer memory, 
the compressed video bitstream 42 assembled in accordance with the 
present invention displays the highest quality decoded image. 
Generally, most MPEG decoders include a buffer that is no smaller 
than 40960 bytes, and may be as large as 241,664 bytes. 

In addition to storing the encoded encoded I frame 108, as 
illustrated in FIG. 4, the video encoder 38 also includes stored 
data specifying an encoded MPEG null frame 112, various headers 114 
that are required for assembling the GOP 52 , and bitstream stuffing 
116 ' As described in greater detail below, a 

compressed-video-bitstream assembler 118 included in the video 
encoder 38 appropriately concatenates data for the encoded I frame 
108, the null frame 112, headers 114, and perhaps the bitstream 
stuffing 116 to assemble at least one GOP 52 for the compressed 
video bitstream 42 depicted in FIG. 4. A table set forth below 
lists various elements that must be included in the compressed 
video bitstream 42 to be decodable in accordance respectively with 
20 the MPEG-l and MPEG-2 standards. 



115 
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MPEG-1 

sequence_header 

group_of_pictures 

picture^ start code 
I Frame Data 

picture^ start code 
Null Frame Data 



sequence end code 



s s As indicated in the preceding tables, if the serial system 

p stream 46 is to be decodable in accordance with the MPEG-1 
% standard, then it begins with a sequence_header 122, illustrated in 
^10 FIG. 4, that the compressed-video-bitstream assembler 118 extracts 
from the headers 114. The serial system stream 46 then includes 
one or more GOPs 52 which establish a time interval during which a 
decoder, while decoding the compressed video bitstream 42, produces 
an image of the still-image data 104. The compressed video 
15 bitstream 42 then ends with a sequence_end code 124. Each GOP 52 
included in the compressed video bitstream 42 begins with a 
group_start code 126 that the compressed-video-bitstream assembler 
118 extracts from the headers 114. A copy of the encoded I frame 



MPEG-2 


s equence_header 
sequence_extension 










picture_header 
picture_coding_ex- 
tension 






I Frame Data 






picture_header 
picture_coding_ex- 
tension 






Null Frame Data 


sequence_end code 
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108, to which the compressed-video-bitstream assembler 118 prefixes 
a picture_start code 128 that the compressed-video-bitstream 
assembler 118 extracts from the headers 114, follows immediately 
after the picture_start code 128. The encoded I frame 108 is 
5 followed by one or more copies of the null frame 112 to each one of 
which the compressed-video-bitstream assembler 118 also prefixes 
the picture_start code 128, again extracted from the headers 114. 
The encoded I frame 108 plus the null frames 112 establish a time 
p interval during which a decoder, while decoding the GOP 52,: 
jfiLO produces an image of the still-image data 104. If it is intended 
| to transmit the compressed video bitstream 42 via a communication 
W channel that requires a pre-established bitrate, e.g. via a Tl 
=p telecommunications network, then the compressed-video-bitstream 

5 

j* assembler lis appends sufficient bitstream stuffing lie to each of 
|15 the null frames 112 to satisfy the communication channel's bitrate 

ils 

~£ requirement . 

As indicated in the preceding tables, omission of the 
group_start code 126 from the GOP 52 illustrated in FIGs 4 yields 
an illustration accurately depicting a compressed video bitstream 
20 42 in accordance with the present invention that a MPEG-2 decoder 
may process. For an MPEG-2 compressed video bitstream 42, the 
compressed-video-bitstream assembler 118 prefixes both a pic- 
turejieader and a picture_coding_extension to the encoded I frame 
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108 and null frames 112 rather than the picture_start code required 
for a MPEG-1 compressed video bitstream 42. 

While the tables set forth above specify a minimum amount of 
header data absolutely necessary for the compressed video bitstream 
5 42 to be decodable, the compressed video bitstream 42 in accordance 
with the present invention preferably includes the header data set 
forth in the following tables. 



MPEG-1 






sequence_header 




group_of_pictures 






picture^ start code 






I Frame Data 






picture_ start code 






Null Frame Data 






Stuffing as needed 


sequence_end code 



MPEG-2 



sequence_header 
sequence_extens ion 
group__start code 



p ictur e_header 
picture_coding_ex- 
tension 
I Frame Data 
p ictur e_header 
picture_coding_ex- 
tension 
Null Frame Data 
Stuffing as needed 



sequence_end code 



From the preceding tables it is readily apparent that each GOP 52 
15 in the preferred compressed video bitstream 42, in addition to the 
I Frame and Null Frame data, includes both the codes for specifying 



- 18 



DOCKET NO. 2134 

the start of a sequence, and the codes for specifying the start of 
a GOP. 

While there exist various differing ways in which the null 
frame 112 may be encoded, the null frame 112 in accordance with the 
present invention for an MPEG-1 compressed video bitstream 42 
preferably is that set forth below. Please note that in the 
following tables the MPEG-1 null frame 112 employs a single slice 
64 to specify an entire frame 62 of decompressed video. However, 
the MPEG-2 null frame 112 specifies decompressed video having a 
maximum height of one slice 64, i.e. sixteen (16) immediately 
vertically-adjacent, non-interlaced television scan lines 66, and 
which spans the frame's width. 
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MPEG-1 NOLL FRAME 



PICTURE START CODE 



temp_ref 



0000 0000 0000 0000 0000 

0001 0000 0000 

(Ten (10) bit field that 



PJTYPE 


1 010 


vbv^delay 


1111 1111 1111 1111 


full_pel_forward_vector 


0 


f orwar d_f _code 


1 001 


(Start Code Alignment 


0000000 


Stuffing) 





SLICE MIN START 



0000 0000 0000 0000 0000 

0001 0000 00001 



quantize scale 



00001 



ext r a_s 1 ice_bi t 


1 0 


first macroblock address 


1 1 


increment (1) 




macroblock_type 


1 001 


(hor_f orwar d) 




motion_forward code 


1 



mot i on_ver t ica l_code 

macro block escapes | 000 0000 1000 

repeat for NumEs capes in the 
frame 



last macroblock_address _in« 
crement 



(Selected from addrinctab 
set forth below.) 



macroblock type hor forward 001 



- 20 - 



DOCKET NO. 2134 





mot i on_f orward_code 


1 




motion vertical code 


1 



Parameters used in specifying the MPEG-1 null frame 112 are as 
5 follows. 

TotalBlocks = frame_width x frame_height / (16 x 16)^ 

NumEscapes = (TotalBlocks - 2) / 33 

NumRemainingBlocks = TotalBlocks - (NumEscapes x 33) - 2 

- Addrinctab is a table which specif ies variable length codes 

^10 that represent the NumRemainingBlocks calculated above. The 

£j addrinctab table includes thirty-three (33) pairs of numbers. The 

ffj first pair of numbers specifies a variable length code to be used 

£ if the NumRemainingBlocks = 1, the second pair of numbers specifies 

k a variable length code to be used if the NumRemainingBlocks = 2, 

pl5 and so on. The first number in eactr pair represents a binary 

j3 number that specifies the variable length code to be used, and the 

w second number in each pair specifies the number of binary digits in 

the variable length code. For example, if the NumRemainingBlocks 

equals '5, it is represented by the binary code 0010. 

20 {NumberofBits, Value} 

addrinctab[33] = 

{ 

{0x01,1}, {0x03,3}, {0X02,3}, {0x03,4), 
{0x02,4}, {0x03,5}, {0x02,5}, {0x07,7), 
25 {0x06,7}, {0x0b,8}, {0x0a,8}, {0x09,8), 

{0x08,8}, {0x07,8}, {0x06,8}, {0x17,10), 
{0X16,10}, {0X15,10}, {0X14,10}, {0X13,10), 
{0x12,10}, {0x23,11}, {0x22,11}, {0x21,11), 
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{0x20,11}, {Oxlf,ll}, {Oxle,ll}, {Oxld,ll), 
{Oxlc,ll}, {Oxlb,ll}, {Oxla,ll}, {0x19,11), 
{0x18,11}, 

}; 

The null frame 112 in accordance with the present invention 
for an MPEG-2 compressed video bitstream 42 preferably is that set 
forth below. 
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MPE6-2 NULL 


FRAME 


PICTURE_START CODE 


0000 0000 0000 0000 0000 

0001 0000 0000 




temp_ref 


(Ten (10) bit field that 
lncreiuenLS eacn rrame, ) 




P_TYPE 


010 




vbv_delay 


1111 1111 1111 1111 




full_pel_forward code 


0 




f orwar d_f _code 


111 




(Start Code Alignment 
Stuffing) 


0000000 


EXT_ 


START_CODE 


0000 0000 0000 0000 0000 

0001 1011 0101 


CODING EXTENSION 


1000 




f orw_hor_f _code 


0000 (Set to value speci- 
fied by encoding pa- 
rameters.) 




f orw_ver_f_code 


0000 (Set to value speci- 
fied by encoding pa- 
rameters . ) 




back_hor_f_code 


0000 (Set to value speci- 
fied by encoding pa- 
rameters . ) 




back_ver_f_code 


0000 (Set to value speci- 
fied by encoding pa- 
rameters . ) 




intra_dc_prec 


00 (Set to value speci- 
fied by encoding pa- 
rameters . ) 




picture_structure 


00 (Set to value speci- 
fied by encoding pa- 
rameters . ) 
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top_field_first 



0 



(Set to value speci 
fied by encoding pa- 
rameters . ) 



frame__pred dct 



0 



(Set to value speci- 
fied by encoding pa- 
rameter^) 



concealment motion vectors 



0 



(Set to value speci- 
fied by encoding pa- 
rameters • ) 



q_scale_type 



0 



(Set to value speci 
fied by encoding pa- 
rameters • ) 



intra vie format 



0 



(Set to value speci- 
fied by encoding pa- 
rameters . ) 



alternate scan 



repeat first field 



chrom_420_type 



progressive frame 



composite_display_flag 



for each slice until NumSlices: 
SLICE_MIN_START +1 for each 
slice 



quantize scale 



0 (Set to value speci- 
fied by encoding pa- 
rameters . ) 

(Set to value speci- 
fied by encoding pa- 
rameters . ) 

0 (Set to value speci- 
fied by encoding pa- 
rameters . ) 

0 (Set to value speci- 
fied by encoding pa- 
rameters . ) 

(Set to value speci 
fied by encoding pa 
rameters . ) 

00000 0000 0000 0000 0000 

0001 0 000 00001 

00001 



extra slice bit 



first macroblock_address 
increment (1) 
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macroblock type 
(hor forward) 


001 




motion forward code 


1 




motion vertical code 


1 




macro block escapes 

repeat for NumEscapes in the 

slice 


000 0000 1000 




last macroblock_address 
increment 


(Selected from addrinctab 
set forth above.) 




macroblock type hor forward 


001 




motion_forward_code 


1 




mot i on_ver t i ca l_code 


1 



Parameters used in specifying the MPEG-2 null frame 112 are as 
follows. 



TotalBlocksPerSlice = PictureWidth / 16 

NumEscapesPerSlice = (TotalBlocksPerSlice - 2) / 33 

NumRemainingBlocksPerSlice = TotalBlocksPerSlice - 

(NumEscapesPerSlice x 33) - 2 
NumSlices = PictureHeight/16 

Set forth below is a listing of a computer program in the 
C++ programming language for generating the null frame 112. 
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/ / ^/ ///// /////////////////////////////////////////////////////// 

/// The following code is a sample of the creation of 
/// a NULL P frame 

void putbits (int BitValue ,int BitLength); 

// putbits writes BitLength bits into MPEG stream havinq a 

// value of BitValue 

void alignbits ( ) ; 

/// writes enough 0 bits to the MPEG stream to align the bits 
// to a byte boundary 

/// taken from MPEG-1 and MPEG-2 specifications: 



35 



static 
{ 

{0x01 
{0x02 
{0x06 
{0X08 
{0X16 
{0x12 
{0x20 
{Oxlc 
{0x18 

}; 

/define 
#define 
#def ine 
/define 
/define 
/define 
/define 
/define 



VLCtable addrinctab[33]= 



,1}, {0x03,3}, 

,4}, {0x03,5}, 

,7}, {0x0b,8}, 

,8}, {0X07,8}, 

,10}, {0X15,10}, 

,10}, {0X23,11}, 

,11}, {0xlf,ll}, 

,11}, {0xlb,ll}, 
/ll} 



{0X02,3}, 

{0X02,5}, 

{0x0a,8}, 

{0x06,8}, 

{0x14,10}, 

{0x22,11}, 

{0xle,ll}, 

{0xla,ll}, 



{0X03,4}, 
{0X07,7}, 
{0X09,8}, 
{0x17,10} 
{0x13,10} 
{0X21,11} 
{0xld,ll} 
{0x19,11} 



PICTURE_START_CODE 0x00000100 
P_TYPE 2 

SLICE_MIN_START 0x00000101 
EXT_START_CODE 0x0 0 0 0 0 1BA 
C0DING_ID 0XA 
TOP_FIELD 1 
BOTTOM_FIELD 2 
FRAME PICTURE 3 
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/ The following code writes a single Null MPEG-1 P Frame to the 
compressed video bitstreanu TempRef is a number, 
starting with 0 that is incremented every frame after 
the start of the GOP and reset to 0 at each new GOP 
The VBV delay is calculated for each frame 
or set to Oxffff for non constant bit rate 



MakeMpeglNullFrame (int TempRef, int VBVDelay) 
{ 

10 int fr,iii; 

int TotalBlocks = (picture_width *picture_height) / (16*16) ; 
int NumEscapes = (TotalBlocks - 2)/33; 

int NumRemainingBlocks = TotalBlocks - NumEscapes*33 - 2; 



15 



at 



h25 



30 



35 



putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 



PICTURE_START_C0DE / 32) ; /// header 
TempRef , 10) ; 
P_TYPE,3) ; 
VBVDelay, 16) ; 
0x0,1) 



0x1,3) 
0x0,7) 



/ /macroblockjtype 
// forward_f_code 
// stuffing so start code aligns 



SLICE_MIN_START,32) ; // slice start 



0x1,5) 
0x0,1) 
0x1,1) 
0x1,3) 
0x1,1) 
0x1,1) 



// quantize_scale 

// extra_slice bit 

// macroblock increment (1) 

// macroblock type (hor_forward) 

// motion forward code 



// motion_vertical_code 
for (iii = 0; iii < NumEscapes; iii+=l) 
putbits (0x8,11); // escape 
putbits (addrinctab [NumRemainingBlocks] .code, 
addrinctab[ NumRemainingBlocks] .len) ; 



putbits (0x1,3) 
putbits (0x1,1) 
putbits (0x1,1) 
putbits (0x0,1) 
alignbits() ; 



// macroblock type (hor_forward) 

// motion_forward_code 

// motion_vertical_code 

// stuffing 



} 
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/// The following code writes a single Null MPEG-2 P Frame to the 

// compressed video bitstream. TempRef is a number, 

// starting with 0 that is incremented every frame after 

// the start of the GOP and reset to 0 at each new GOP 

// The VBV delay is calculated for each frame 

// or set to Oxffff for non constant bit rate 

MakeMpeg2NullFrame (int TempRef, int VBVDelay) 



int fr,iii,CurrentSlice; 

int TotalBlocksPerSlice = ( tee. width) / (16) ; //*2 for each field 
int NumEscapesPerSlice = (TotalBlocksPerSlice - 2)/33; 
int NumRemainingBlocksPerSlice = TotalBlocksPerSlice - 
NumEscapesPerSlice*33 - 2; 
int NumSlices = tee .height/ 16; 



putbits (PICTURE_START_CODE,32) ; /// header 

putbits (TempRef ,10) ; 

- putbits ( P__TYPE , 3 ) ; / / 2 

putbits (VBVDelay, 16) ; 

putbits (0x0,1); //for fullj?el_forward code 

putbits (0x7,3); // forward_f_code " 5 

putbits (0x0,7); //// stuffing so start code aligns 

AddNullPictureExtension(3) ; // 3=frame picture 
alignbits(); // add bytes to align to boundaries 

/// create Sequence of macro_blocks for each slice 
for (CurrentSlice = 0; CurrentSlice < NumSlices; 
Currents 1 ice+=l ) 



putbits (SLICE_MIN_START+CurrentSlice,32); // slice start 



putbits (0x1,5) 

putbits (0x0,1) 

putbits (0x1,1) 

putbits (0x1,3) 



// quantizer_scale 
// extra_slice_bit 
// macroblock increment (1) 
// macroblock_type (MC forward, 
// Not Coded) 
// motion_forward_code 
// motion vertical code 



putbits (0x1,1); 
putbits (0x1,1); 



// for add escapes for number of escapes 

for (iii = o; iii < NumEscapesPerSlice; iii+=l) 
putbits (0x8,11); ///escape code 
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// add address increment for remainding blocks 

putbits (addrinctab[NumRemainingBlocksPerSlice] . code, 
addrinctab[NumRemainingBlocksPerSlice] . len) ; 

/// last macro_block per slice 

putbits (0x1,3); ///macroblock type MC not coded 

/ / macroblock_modes ( ) 
putbits (0x1,1); // motion_forward_code 

putbits (0x1,1); // motion_vertical_code 

putbits (0x0,5); /// align 

alignbits(); // add bytes to align to boundaries 

} // for each slice 



} 
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The AddNullPictureExtension subroutine set forth below writes 
picture extensions to the compressed video bitstream 42. 



AddNullPictureExtension ( int Null_picture_structure) 

// picture^structure = 1 top field; 2 bottom field; 3 frame 

picture 

{ 

alignbits() ; 



putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 

putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 
putbits 



EXT_START_CODE,32) ; /* extension_start_code */ 
C0DING_ID,4) ; /* extension_start_code_identifier */ 
forw_hor_f_code,4) ; /* forward_horizontal_f_code */ 
forw_vert_f_code, 4) ; /* forward_vertical_f_code */ 
back_hor_f _code , 4 ) ; /* backward_horizontal_f_code */ 
backjver t_f _code , 4 ) ; /* backward_vertical_f_code */ 
dc_prec,2); /* intra_dcjprecision */ 
Null_picture_structure,2) ; /* picture_structure */ 
(pict_struct==FRAME_PICTURE) ?topf irst: 0, 1) ; 

/* top_field_first */ 
frame_pred_dct,l) ; /* frame_pred_frame_dct */ 
0,1); /* concealment jnotion_vectors*/ 
q_scale_type,l) ; /* q_scale_type */ 
0,1); /* intra_vlc_format force it to 0 */ 
altscan,l); /* alternatejscan */ 
repeatfirst,l) ; /* repeat_f irst_f ield */ 
chroma_420J:ype,l) ; /* chroma_420_type */ 
prog_frame, 1) ; /* progressive_frame */ 
0,1); /* composite_display_flag */ 



} 
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If the video encoder 38 depicted in FIG. 4 is implemented by 
a computer program executed by a Pentium® processor operating at 
450 MHz, then the video encoder 38 can encode the compressed video 
bitstream 42 in accordance with the present invention at two 
hundred and fifty (250) times faster than a decoder would present 
visual images from the decoded compressed video bitstream 42. 

In addition to the MPEG-l and MPEG-2 standards identified 
above, additional details regarding MPEG video compression and 
assembling the compressed video bitstream 42 are set forth in the 
following publications that are hereby incorporated by reference. 
"MPEG Video Compression Standard" by Joan L. Mitchell, 
William B. Pennebaker, Chad E. Fogg, and Didier J. LeGall 
published by International Thomson Publishing, copyright 



1996. 



i 15 "Measuring and Regulating Synchronization of Merged Video 

j and Audio Data," Patent Cooperation Treaty ("PCT") 

international patent application PCT/US94/09565 published 

7 March 1996, as WO 96/07274. 

Although the present invention has been described in terms of 
20 the presently preferred embodiment, it is to be understood that 
such disclosure is purely illustrative and is not to be interpreted 
as limiting. Consequently, without departing from the spirit and 
scope of the invention, various alterations, modifications, and/or 
alternative applications of the invention will, no doubt, be 
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suggested to those skilled in the art after having read the 
preceding disclosure. Accordingly, it is intended that the 
following claims be interpreted as encompassing all alterations, 
modifications, or alternative applications as fall within the true 
spirit and scope of the invention. 
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